Date: Sat, 26 Mar 94 04:30:21 PST From: Ham-Space Mailing List and Newsgroup Errors-To: Ham-Space-Errors@UCSD.Edu Reply-To: Ham-Space@UCSD.Edu Precedence: Bulk Subject: Ham-Space Digest V94 #71 To: Ham-Space Ham-Space Digest Sat, 26 Mar 94 Volume 94 : Issue 71 Today's Topics: How to Talk to Mir? Navstar GPS Constellation Status (94-03-23): Correction On-line satellite schedules? Telecom and Meteors (2 msgs) what does NO -2 N4USH mean? Send Replies or notes for publication to: Send subscription requests to: Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the Ham-Space Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives/ham-space". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: Fri, 25 Mar 1994 21:56:35 GMT From: ihnp4.ucsd.edu!dog.ee.lbl.gov!agate!boulder!cnsnews!spot.Colorado.EDU!millerpe@network.ucsd.edu Subject: How to Talk to Mir? To: ham-space@ucsd.edu I am a new ham and just beginning to read about satellite communications with ham radio. I have seen an article that explained that the Mir space station was fairly easy to communicate with. What is the minimum setup that might mbe necessary for me to attempt a contact - or even listen to the station. I have downloaded a few satellite tracking packages and if I am using them correctly I believe I know when it sould be overhead. The article also mentioned that 145.55 MHZ was the frequency to use. Any help or tips would be greatly appreciated. Peter Miller millerpe@spot.colorado.edu -- =========================================================================== Peter M. Miller Home: 303-494-6990 Computing and Network Services - Small Systems Work: 303-492-4866 University of Colorado - Boulder millerpe@spot.colorado.edu ------------------------------ Date: 25 Mar 1994 10:50:54 -0800 From: dont-send-mail-to-path-lines@ames.arpa Subject: Navstar GPS Constellation Status (94-03-23): Correction To: ham-space@ucsd.edu The Navstar GPS Constellation Status table dated 94-03-23 contains an error in the notes section. Some of the details in note 8 actually refer to PRN13 not PRN03. Both of these Block I satellites are currently set unhealthy. I have revised the table and notes 8 and 12 now correctly reflect the situation. Thanks to Francine Vannicola of the U.S. Naval Observatory for pointing out the error. Navstar GPS Constellation Status (94-03-25) Blk NASA Orbit Launch II PRN Internat. Catalog Plane Date Seq SVN Code ID Number Pos'n (UT) Clock Available/Decommissioned -------------------------------------------------------------------------------- Block I 01 04 1978-020A 10684 78-02-22 78-03-29 85-07-17 02 07 1978-047A 10893 78-05-13 78-07-14 81-07-16 03 06 1978-093A 11054 78-10-06 78-11-13 92-05-18 04 08 1978-112A 11141 78-12-10 79-01-08 89-10-14 05 05 1980-011A 11690 80-02-09 80-02-27 83-11-28 06 09 1980-032A 11783 80-04-26 80-05-16 91-03-06 07 81-12-18 Launch failure 08 11 1983-072A 14189 83-07-14 83-08-10 93-05-04 09 13 1984-059A 15039 C-1 84-06-13 Rb 84-07-19 10 12 1984-097A 15271 A-1 84-09-08 Rb 84-10-03 11 03 1985-093A 16129 C-4 85-10-09 Rb 85-10-30 Block II II-1 14 14 1989-013A 19802 E-1 89-02-14 Cs 89-04-15 05:02 UT II-2 13 02 1989-044A 20061 B-3 89-06-10 Cs 89-08-10 20:46 UT II-3 16 16 1989-064A 20185 E-3 89-08-18 Cs 89-10-14 20:21 UT II-4 19 19 1989-085A 20302 A-4 89-10-21 Cs 89-11-23 03:13 UT II-5 17 17 1989-097A 20361 D-3 89-12-11 Cs 90-01-06 03:30 UT II-6 18 18 1990-008A 20452 F-3 90-01-24 Cs 90-02-14 22:26 UT II-7 20 20 1990-025A 20533 B-2 90-03-26 Cs 90-04-18 23:13 UT II-8 21 21 1990-068A 20724 E-2 90-08-02 Cs 90-08-22 15:00 UT II-9 15 15 1990-088A 20830 D-2 90-10-01 Cs 90-10-15 00:39 UT Block IIA II-10 23 23 1990-103A 20959 E-4 90-11-26 Cs 90-12-10 23:45 UT II-11 24 24 1991-047A 21552 D-1 91-07-04 Rb 91-08-30 04:44 UT II-12 25 25 1992-009A 21890 A-2 92-02-23 Cs 92-03-24 11:00 UT II-13 28 28 1992-019A 21930 C-2 92-04-10 Cs 92-04-25 20:32 UT II-14 26 26 1992-039A 22014 F-2 92-07-07 Cs 92-07-23 19:43 UT II-15 27 27 1992-058A 22108 A-3 92-09-09 Cs 92-09-30 20:08 UT II-16 32 01 1992-079A 22231 F-1 92-11-22 Cs 92-12-11 14:49 UT II-17 29 29 1992-089A 22275 F-4 92-12-18 Cs 93-01-05 16:39 UT II-18 22 22 1993-007A 22446 B-1 93-02-03 Cs 93-04-04 05:20 UT II-19 31 31 1993-017A 22581 C-3 93-03-30 Cs 93-04-13 20:53 UT II-20 37 07 1993-032A 22657 C-4 93-05-13 Cs 93-06-12 16:15 UT II-21 39 09 1993-042A 22700 A-1 93-06-26 Cs 93-07-20 12:54 UT II-22 35 05 1993-054A 22779 B-4 93-08-30 Cs 93-09-28 19:29 UT II-23 34 04 1993-068A 22877 D-4 93-10-26 Cs 93-11-22 18:20 UT II-24 36 06 1994-016A 23027 C-1 94-03-10 Projected usable 94-04-18 38 To be launched on need in FY '94 33 To be launched on need in FY '94 40 To be launched on need in FY '95 30 To be launched on need in FY '95 Notes 1. NASA Catalog Number is also known as NORAD or U.S. Space Command object number. 2. No orbital plane position = satellite no longer operational. 3. Clock: Rb = Rubidium; Cs = Cesium 4. S/A had been enabled on Block II satellites during part of 1990; S/A off between about 10 August 1990 and 1 July 1991 due to Gulf crisis; standard level re-implemented on 15 November 1991. Currently, PRN15 and PRN20 appear to have little or no S/A imposed. 5. Anti-spoofing was activated on 94-01-31 at 0000 UT on all Block II satellites. (ref. NANU 050-94042) 6. PRN number of SVN32 was changed from 32 to 01 on 93-01-28. 7. PRN03 is operating on Rb clock without temperature control. 8. PRN03 was set unhealthy on 94-02-27 at 0320 UT. It was unusable beginning at 0233 UT on 94-02-27 and will remain unusable until further notice. (ref. NANU 083-94059) 9. The decommissioning date for PRN06/SVN03 is the date of termination of operations of this satellite (ref. USNO) and is about 3 weeks later than the date GPSIC gives for "deactivation". 10. The PRN06/SVN36 launch included the SEDS-2 tether experiment on the Delta II rocket body (object 23028, 1994-016B). 11. PRN09 was unusable beginning 93-10-15 1200 UT until 93-12-07 1940 UT due to testing. (ref. NANU 327-93288 and NANU 402-93341) 12. PRN13 was set unhealthy on 94-02-27 at 1302 UT and will remain unusable until further notice due to "end of life testing." (ref. NANU 083-94059 and USNO). It is unlikely that PRN13 will return to service. (ref. USNO) 13. The degraded C/A-code performance of PRN19 was corrected effective 94-01-04 at 0000 UT. (ref. NANU 343-93294, NANU 396-93337, and NANU 006-94010) 14. PRN24 was unusable from 94-01-23 1745 UT until 94-02-01 1516 UT due to a change in operational frequency standard from Cs to Rb. (ref. NANU 023-94023, NANU 029-94024, NANU 034-94032, and USNO) =============================================================================== Richard B. Langley Internet: LANG@UNB.CA or SE@UNB.CA Geodetic Research Laboratory BITnet: LANG@UNB or SE@UNB Dept. of Geodesy and Geomatics Engineering Phone: (506) 453-5142 University of New Brunswick FAX: (506) 453-4943 Fredericton, N.B., Canada E3B 5A3 Telex: 014-46202 =============================================================================== ------------------------------ Date: Fri, 25 Mar 94 07:05:37 GMT From: ihnp4.ucsd.edu!usc!howland.reston.ans.net!agate!msuinfo!netnews.upenn.edu!news.amherst.edu!nic.umass.edu!usenet@network.ucsd.edu Subject: On-line satellite schedules? To: ham-space@ucsd.edu Is there an on-line source of data about Oscar and RS satellite schedules of operation? Albert S. Woodhull Hampshire College, Amherst, MA, USA awoodhull@hamp.hampshire.edu ------------------------------ Date: Fri, 25 Mar 94 07:02:29 GMT From: ihnp4.ucsd.edu!agate!msuinfo!netnews.upenn.edu!news.amherst.edu!nic.umass.edu!usenet@network.ucsd.edu Subject: Telecom and Meteors To: ham-space@ucsd.edu In Article mack@ncifcrf.gov (Joe Mack) writes: > [Communication via meteors has] never taken off and as far as I can tell it >'s only being used by experimenters. I believe I read a few years ago about meteor scatter being used by remotely located unmanned weather stations to relay information to central locations using packet radio techniques. The information is bundled into packets that are small enough and transmitted rapidly enough that an entire packet has a good chance of getting through in its entirety. The packet protocol verifies receipt of packets and causes retransmission of unverified packets until they are successfully received. Since the total volume of information is relatively small the overall data rate is satisfactory. My recollection is vague, but this could have been an article in the journal Science, and perhaps it was as long ago as the late '70s. I think I recall a color picture of a remote weather station in the arctic on the cover of the issue. I would be pleased if someone could find the reference and send it to me. I wonder if hams have done work on meteor scatter packet transmission? It would have to be done on clear channels and with very specialized parameters (short packets, unlimited retries, fast response). On a related topic, I have sometimes noticed when propagation is marginal but not entirely dead on 10 or 15 meters that weak signals will "pop up" briefly and then return to their normal level. I have suspected, but do not know for sure, that this is due to meteor trail reflections. Albert S. Woodhull N1AW Hampshire College, Amherst, MA, USA awoodhull@hamp.hampshire.edu ------------------------------ Date: 25 Mar 1994 18:01:18 GMT From: ihnp4.ucsd.edu!dog.ee.lbl.gov!agate!blanket.mitre.org!linus.mitre.org!wralston.mitre.org!user@network.ucsd.edu Subject: Telecom and Meteors To: ham-space@ucsd.edu In article <2mv5b9$t13@nic.umass.edu>, awoodhull@hamp.hampshire.edu wrote: > > In Article mack@ncifcrf.gov (Joe Mack) writes: > > > [Communication via meteors has] never taken off and as far as I can tell it > >'s only being used by experimenters. > > I believe I read a few years ago about meteor scatter being used by > remotely located unmanned weather stations to relay information to > central locations using packet radio techniques. The information is > bundled into packets that are small enough and transmitted rapidly enough > that an entire packet has a good chance of getting through in its > entirety. The packet protocol verifies receipt of packets and causes > retransmission of unverified packets until they are successfully received. > Since the total volume of information is relatively small the overall data > rate is satisfactory. There is a system call SNOTEL operating in the western US which collects information on snowpack levels operated by the US Dept of Agriculture. The equipment was built my Meteor Communications Corporation, Kent, WA. The ASAF used to operate a meteor-burst link in Alaska as a back up to a satellite link which was frequently disrupted by aurora. I think this system was dismantled. A number of meteor burst telemetry systems exist internationally for hydro-meteorological data collection. At one time there were systems operating in Egypt and in Uganda - I don't know of their current status. -- Bill wtr@mitre.org * I babble too incoherently to speak for my employer * ------------------------------ Date: Fri, 25 Mar 1994 19:31:49 GMT From: mdisea!mothost!schbbs!news@uunet.uu.net Subject: what does NO -2 N4USH mean? To: ham-space@ucsd.edu In article <9403242326.AA24705@freenet3.scri.fsu.edu>, bmm1@freenet2.scri.fsu.edu (Bruce M. Marshall) says: > >I am trying to establish an uplink to UO22 and so far have all I have >gotten is the message 'NO -2 N4USH'. What does this mean? Does anyone >have any info on what all the information that OSCARS 22, 23 & 25 >routinely downlink means? Some is obvious, some is not. I have found >some problems and corrected them and am waiting for evening passes to >check them out. Any suggestions or comments on debugging uplinks would >be appreciated. >thanks, Bruce. N4USH >-- >Bruce M. Marshall bmm1@freenet.fsu.edu voice 615 481 0990 fax 615 481 8039 It means that the file that you requested to be downloaded is no longer availabledownload by the file server. There is a parameter in the header of the file controlled by the uploader which specifies how long the file is to kept active in the directory. If its something you really need, upload a message to "ALL" asking for the original uploader or anyone else who might have it to upload it again. Hope this helps. 73's Ned Stearns AA7A email: ned_stearns@email.mot.com ------------------------------ End of Ham-Space Digest V94 #71 ******************************